home *** CD-ROM | disk | FTP | other *** search
/ The X-Philes (2nd Revision) / The X-Philes Number 1 (1995).iso / xphiles / hp48_2 / exec / comp.sys.handhelds_2145_000001.msg < prev   
Internet Message Format  |  1995-03-31  |  6KB
  1. Path: helens!shelby!decwrl!elroy.jpl.nasa.gov!sdd.hp.com!hp-pcd!hpcvia!scottb
  2. >From: scottb@hpcvia.CV.HP.COM (Scott_Burke)
  3. Newsgroups: comp.sys.handhelds
  4. Subject: Re: Unix-link PATH searching for the HP-48SX
  5. Message-ID: <31210042@hpcvia.CV.HP.COM>
  6. Date: 12 Jul 90 16:13:43 GMT
  7. References: <1570006@hpnmdla.HP.COM>
  8. Organization: Hewlett-Packard Co., Corvallis, Oregon
  9. Lines: 119
  10.  
  11. Here is a re-write of EXEC, a program written by Darryl Okahata that implements 
  12. path searching on the 48sx.  It addresses all of the unresolved issues Darryl
  13. mentions in his posting.  It also fixes a bug, is half the size, and preserves
  14. the speed of the original.
  15.  
  16. Entry syntax:  Enter arguments and name of function on the stack.  Then execute
  17. 'EXEC'.  (I assign EXEC to the left-shifted EVAL key, since I never use ->Q.)
  18. The variable 'TRAIL' must be present in the HOME directory.  It should be a list
  19. of all "leaves" in the directory tree.  To understand this further, imagine a 
  20. simple directory structure: (where W1, W2, W3, and GAMES are the "leaves")
  21.  
  22.                                    HOME
  23.                                     /\
  24.                                 WORK  PLAY
  25.                                / / \      \
  26.                              W1 W2 W3    GAMES
  27.  
  28. The purpose of 'EXEC' is to execute functions contained in the non-current sub-
  29. directory.  If a function resides in W2, then 'TRAIL' must contain the list:
  30. { HOME WORK W2 } for that function to be findable.  However, it is only neces-
  31. sary to include the path { HOME WORK } in 'TRAIL' if you SPECIFICALLY want to
  32. search { HOME WORK } BEFORE any of W1, W2, or W3.  In that case, put the list
  33. { HOME WORK } BEFORE { HOME WORK W1 } etc. in the list 'TRAIL'.  In the same 
  34. vein, it is only necessary to include HOME or { HOME } in 'TRAIL' if it should
  35. be searched BEFORE other subdirectories.
  36.  
  37. Thus, a normal 'TRAIL' variables for the above structure might be:
  38.  
  39. { { HOME WORK W1 } { HOME WORK W2 } { HOME WORK W3 } { HOME PLAY GAMES } }
  40.  
  41. In Darryl's version of EXEC, he allowed the inclusion of a blank list { } to
  42. represent the current working directory.  I have two approaches to that 
  43. problem.  First (the elegant way):  The current subdirectory ought to be one
  44. of the full lists in 'TRAIL', so nothing special needs to be done.  Second
  45. (the other way):  IF YOU REQUIRE THAT THE CURRENT DIRECTORY BE SEARCHED FIRST,
  46. then include the optional line of code shown in the listing below.  That line
  47. checks for the presence of the function in the current directory BEFORE it does
  48. anything else.  However, it slows down the code, and makes it bigger, so I 
  49. don't include it in my personal version.
  50.  
  51.  
  52.  
  53. Here are solutions/workarounds to some of Darryl's comments:
  54.  
  55. > 1. EXECPATH does not necessarily come from the HOME directory.  Strange
  56. >    things will happen if EXECPATH resides in the "current directory" or
  57. >    in one of the directories given by EXECPATH.
  58.  
  59.   I require that 'TRAIL' be present in the HOME directory.  It's not a big
  60.   deal.  If you don't like to clutter your HOME directory, I suggest you
  61.   implement the { HOME MAIN } work-around mentioned in a previous note, 
  62.   where HOME contains a whole bunch of garbage, but MAIN is the normal main
  63.   working directory and right-shift ' (HOME) is assigned to << MAIN >>.
  64.  
  65. > 3. EXEC is slow.  The overhead in using EXEC is at least 0.1 sec (I
  66. >    don't know what the overhead in using SVS is, however).  The actual
  67. >    overhead depends on how large and complex your EXECPATH happens to
  68. >    be.  EXEC should be rewritten in assembly language.  It should,
  69. >    perhaps, keep more things on the stack and not in local variables.
  70.  
  71.   With a large 'TRAIL' list, you're going to see a performance hit, even
  72.   in assembly.  Local variables vs. stack operations have negligible speed
  73.   differences in the case of the type of code we're writing here.  It's
  74.   only when you're doing things like filtering lists of tens or hundreds of
  75.   objects that it's noticeably faster to do it all on the stack.  Therefore,
  76.   in many cases, it's faster to use local variables because debugging is SO
  77.   MUCH SIMPLER.
  78.  
  79. > 4. EXEC is big (240 bytes).
  80.  
  81.   Make that 107 bytes (or 124.5 with the current directory check first)
  82.  
  83.  
  84.  
  85. Oh yeah, the bug in the other version...  If a function calls other routines
  86. it expects to be in the same directory as it is executing from (so much for
  87. grammar), Darryl's version crashes, because it has already returned to the
  88. current working directory BEFORE it executes the function it recalled to the
  89. stack.  This is a matter of personal preference, because it occurs to me 
  90. that someone may WANT to execute the function in the current directory; it
  91. may create a global variable that they may want to use.  It's not too hard
  92. to modify the code to work that way, but mine executes everything in it's
  93. original directory and THEN returns to the current one.
  94.  
  95. While I'm thinking of possible bugs, let me mention that my code REQUIRES
  96. the LASTARGS flag to be CLEAR (i.e., enabled).  To do this, execute -55 CF.
  97. The reason is that when I do a RCL to try to get the function code, if the
  98. global variable is not present, RCL returns the name of the function for
  99. another try.  If LASTARGS is SET (i.e., disabled), then the function name
  100. will have to be replicated each loop iteration or stored in a local 
  101. variable.  I don't change flag -55 because that is usually an impolite thing
  102. to do; I'd store the flags and recall them, but we're talking about way too
  103. much overhead there for such a small function.
  104.  
  105.  
  106.  
  107. Here's the code for EXEC.
  108.  
  109. <<
  110.   PATH -> p                store the current working path
  111.   <<
  112.  
  113.  [optional line:]
  114.     VARS OVER POS { EVAL } IFT        check the current directory first
  115.  
  116.     1 TRAIL SIZE FOR i            loop from 1 to the size of TRAIL
  117.       TRAIL i GET EVAL            extract the next path from TRAIL
  118.       IFERR RCL                try to RCL the function code to stack
  119.       THEN                if we fail, don't do anything
  120.       ELSE EVAL p EVAL KILL END        else execute function, reset path, end
  121.     NEXT
  122.     p EVAL                reset path; function wasn't found
  123.   >>
  124. >>
  125.  
  126.  
  127.  
  128. Scott Burke
  129. scottb@hpcvia.cv.hp.com  or  503-750-3978
  130.  
  131.  
  132. From helens!relgyro!shelby!rutgers!usc!sdd.hp.com!hp-pcd!hpcvia!scottb Thu Jul 12 17:04:47 PDT 1990
  133. Status: RO